minor nit: mix of "pegin" and "peg-in" in documentation and error messages.

Currently I run a pruned Elements node on liquidv1 with the default validatepegin setting of 1. Reading the ELIP sounds like it will not be possible when the new options get enabled because getrawtransaction on my pruned Bitcoin node will return the transaction merely while it is in the mempool (which can happen to be mined into a block before Elements node notices the transaction). IMHO it's asking for a race condition.

I don't like the idea of the main chain Bitcoin transaction fee influencing the amount getting burned on liquidv1 during peg-in (after being enabled, of course, but adding the possibility now into the code just begs for enabling it eventually).

Concept ACK now as I did not know the context.

Edit: I see the reasoning now thanks to explanation from Pablo.

Tested ACK 7353687

Rebased to remove the fixup commit - sorry to invalidate your ACK @tomt1664

Currently I run a pruned Elements node on liquidv1 with the default validatepegin setting of 1. Reading the ELIP sounds like it will not be possible when the new options get enabled because getrawtransaction on my pruned Bitcoin node will return the transaction merely while it is in the mempool (which can happen to be mined into a block before Elements node notices the transaction). IMHO it's asking for a race condition.

I don't like the idea of the main chain Bitcoin transaction fee influencing the amount getting burned on liquidv1 during peg-in (after being enabled, of course, but adding the possibility now into the code just begs for enabling it eventually).

Concept NACK

I may be misunderstanding something of course so please help me understand ELIP 202 if you see anything in what I write.

In order for a claim to work, the tx needs to be at least 100 blocks deep, so that is unaffected.
The idea behind using the bitcoin feerate as a reference is to make the tx generation deterministic and independent on the fee rate at the moment of submitting the claim.

@jsarenik

Currently I run a pruned Elements node on liquidv1 with the default validatepegin setting of 1. Reading the ELIP sounds like it will not be possible when the new options get enabled because getrawtransaction on my pruned Bitcoin node will return the transaction merely while it is in the mempool (which can happen to be mined into a block before Elements node notices the transaction). IMHO it's asking for a race condition.

Do you mean with validatepegin=0? Even so, you can still compose the peg-in transaction with subsidy correctly by passing the parent (bitcoin) transaction feerate to claimpegin or createrawpegin if/when this change is ever active on liquidv1.

I don't like the idea of the main chain Bitcoin transaction fee influencing the amount getting burned on liquidv1 during peg-in (after being enabled, of course, but adding the possibility now into the code just begs for enabling it eventually).

As the Liquid Federation drives the tech roadmap for liquidv1, it's their prerogative should they want this enabled to subsidise or discourage low value peg-ins that they must pay for on the mainchain to sweep or spend.

Concept NACK

Noted.

I may be misunderstanding something of course so please help me understand ELIP 202 if you see anything in what I write.

It may be worth reading it again.

Rebased against master

Concept NACK

Noted.

Thank you. I have changed my mind already.

It may be worth reading it again.

I did. But still I would suggest adding some context (maybe a link if it was discussed anywhere). I am not in any office, nor a Telegram channel now, to hear any first-hand gossip from people. And it could be interesting in the future to have an idea about the things happening at the time. Of course no one wants to add wood to fire but misunderstandings like this can happen exactly when there is missing context I'd say.

Thank you for resolution, @delta1 !

Runnung a18a88b with one-liner here-uncommitted change of tweakfedpegscript making my build dirty but seen on each Liquid block at https://anyone.eu.org/liquid/gi.txt

Running ACK a18a88b